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Topics 


■  Moving  Tests  Forward 

■3  Rules  of  Test-Driven  Development  (TDD) 

■TDD  in  Unit,  Integration  and  Acceptance  Testing 

■  Comprehensive  TDD  Process 

■  Pros  and  Cons  of  TDD 
-Q&A 
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Traditional  Development  Cycle 


Testing  Follows  Implementation: 

Unit  tests  are  executed  after  modules  are  completed. 
Integration  testing  follows  implementation. 
Acceptance  testing  begins  at  the  end  of  integration. 


Requirements 


Design 


Implementation 


Integration 

Test 


Unit  Test 
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Moving  Tests  Forward 


Testing  Occurs  Before  Implementation: 

Acceptance  tests  are  developed  as  part  of  the  requirements. 

Integration  tests  are  developed  as  part  of  the  design. 

Unit  tests  are  developed  as  part  of  the  implementation. 

Test  are  executed  throughout  implementation;  test  failures 
drive  what  to  do  next. 


Requirements 


Design 


Implementation 


Write  &  Execute  Unit  Tests 


Write 

Write 

Acceptance 

Integration 

Tests 

Tests 

Execute  Integration  Tests 


Execute  Acceptance  Test 
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Testing  in  an  Agile  Development  Cycle 


Agile  Development  is  not  phase-oriented,  so 
tests  are  executed  throughout  the  cycle,  not 
just  during  implementation. 


Write  &  Execute  Unit  Tests 


Execute  Integration  Tests 


Execute  Acceptance  Test 
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How  Does  Testing  Drive  Development? 


Test-Driven  Development  (TDD)  says  to  create  tests  first 
and  let  them  drive  implementation.  The  three  rules  of 
TDD  demonstrate  how  to  do  that. 


3  Rules  of  TDD 

Do  work 

1.  Write  production  code  only  to  pass  a  failing  test. 

Do  testing 

2.  Write  only  enough  test  eode  to  fail. 

Do  work 

3.  -Write  only  enough  production  code  to  pass. 
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TDD  at  the  Unit  Test  Level 


Unit  tests  are  created  by  developers  to  add  functionality 
to  a  class  or  module. 

At  the  unit  test  level  the  three  rules  are  manifest  in  the 
“red-green-refactor”  approach: 

Red -Green -Refactor 
Write  a  unit  test  that  fails. 

Write  production  code  to  make  the  test  pass. 

Clean  up  both  test  and  production  code. 

for  example  ... 
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TDD  at  the  Unit  Test  Level  (cont’d) 


Using  the  Red-Green-Refactor  approach,  developers 
create  unit  tests  for  individual  modules  as  they  add 
functionality. 
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External  dependencies  are  handled 
by  creating  mock  objects. 


TDD  at  the  Integration  Test  Level 


Initial  integration  tests  are  the  unit  tests  with 
real  components  replacing  mock  objects. 
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Additional  integration  tests  may  be  needed 
to  address  scaling,  loading  or  speed. 


TDD  at  the  Acceptance  Test  Level 


Acceptance  tests  may  take  the  form  of  use  case 
scenarios  executed  via  a  user  interface  ... 

Acceptance 

Test 


Integration 

Tests 
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...or  they  may  be  the  integration  tests 
from  an  external  application. 


Driving  Development  with 
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Refactor 

Integration 

Tests 


Unit 

Tests 
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From  Details  to  Done 


>  Develop  acceptance  test  scenarios  from  groups  of  related 
features. 

>  Develop  integration  tests  for  components  of  a  simple, 
initial  design. 

>  Develop  unit  tests  and  components  using  the  red-green- 
refactor  approach  and  mock  objects. 

>  Integrate  components  by  replacing  mock  objects  with 
actual  components  and  executing  unit  and  integration 
tests. 

>  Execute  acceptance  test  scenarios  to  ensure  all 
functionality  is  complete. 
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Benefits  of  Test-Driven  Development 


Test-Driven 

Development 


Testable  Designs 

Creates  inherently  testable  designs 


Complete  Test  Suite 

Creates  a  test  suite  that  can  be 
retained  for  regression  testing 


Reduced  Scope  Creep 

Fights  developer-induced  scope 
creep  by  limiting  efforts  to  what 
needs  to  be  developed 


Lean  Code  -  Simple  Designs 

Emphasis  on  writing  just  enough 
code  drives  lean  and  simple  solutions 


Definition  of  Done 

Up  front  test  definition  provides  a 
concrete  “definition  of  done” 


Customer  Acceptance  Tests 


Allows  customers  to  write  acceptance 
level  tests  without  needing  to 
understand  technical  details 


Copyright  ©  201 1  Boeing.  All  rights  reserved. 


Drawbacks  of  Test-Driven  Development 


Test-Driven 

Development 


Paradigm  Shift/Learning  Curve 

Can  affect  productivity  due  to  a  lack  of 
necessary  skills  and  experience,  as 
well  as  resistance  to  culture  change 


Drop  in  Perceived  Productivity 

Feature  productivity  is  traded  off  for 
stability,  quality  and  maintainability 


Simple  Designs 

Creates  a  solution,  but  not  necessarily 
the  best  or  most  efficient  solution 


Exhaustive  Testing  Not  Addressed 

Difficult  and/or  inefficient  for  projects 
requiring  exhaustive  testing 


Not  a  Silver  Bullet 

Bad  Requirements  +  Bad  Tests  Bad  Software 
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Defense,  Space  &  Security 

Lean-Agile  Software 


Very  Simple  TDD  Example  - 


Greeter  Test 


[Test] 

public  class  Greeter_Test 

{ 

[TestMethod] 

public  void  TestDisplayHelloWorld ( ) 

{ 

Greeter  myGreeter  =  new  Greeter () 

} 

} 


Compilation  Error 
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World 


Very  Simple  TDD 


Greeter  Test 


[Test] 

public  class  Greeter_Test 

{ 

[TestMethod] 

public  void  TestDisplayHelloWorld ( ) 

{ 

Greeter  myGreeter  =  new  Greeter () 

} 

} 
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(cont’d) 


} 


Greeter ( ) 


Very  Simple  TDD 


Greeter  Test 


[Test] 

public  class  Greeter_Test 

{ 

[TestMethod] 

public  void  TestDisplayHelloWorld ( ) 

{ 

Greeter  myGreeter  =  new  Greeter () 

Assert (myGreeter. getGreeting () ,  "Hello  World") 

} 


Compilation  Error 
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:ont’d) 


Greeter 


public  class  Greeter 

{ 

Greeter ( ) 

} 


Very  Simple  TDD 


Greeter  Test 


[Test] 

public  class  Greeter_Test 

{ 

[TestMethod] 

public  void  TestDisplayHelloWorld ( ) 

{ 

Greeter  myGreeter  =  new  Greeter () 

Assert (myGreeter . getGreeting ( ) ,  "Hello  World") 

} 


Test  Failure 
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:ont’d) 


Greeter 


public  class  Greeter 

{ 

Greeter ( ) 

String  getGreeting () 

{ 

return  "" 

} 


Very  Simple  TDD 


Greeter  Test 


[Test] 

public  class  Greeter_Test 

{ 

[TestMethod] 

public  void  TestDisplayHelloWorld ( ) 

{ 

Greeter  myGreeter  =  new  Greeter () 

Assert (myGreeter . getGreeting ( ) ,  "Hello  World") 

} 
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(cont’d) 


Greeter 


public  class  Greeter 
{ 

Greeter ( ) 

String  getGreeting ( ) 

{ 

return  "Hello  World" 

} 


Very  Simple  TDD  Example 


Greeter  Test 


[Test] 

public  class  Greeter_Test 

{ 

[TestMethod] 

public  void  TestDisplayHelloWorld ( ) 

{ 

Greeter  myGreeter  =  new  Greeter () 

Assert (myGreeter . getGreeting ( ) ,  "Hello  World") 

} 
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(cont’d) 


Greeter 


public  class  Greeter 
{ 

const  String  greeting  =  "Hello  World" 

Greeter ( ) 

String  getGreeting ( ) 

{ 

return  greeting 

} 


Very  Simple  TDD  Example 


Greeter  Test 


[Test] 

public  class  Greeter_Test 

{ 

const  String  expectedGreeting  =  "Hello  World" 

[TestMethod] 

public  void  TestDisplayHelloWorld ( ) 

{ 

Greeter  myGreeter  =  new  Greeter () 

Assert (myGreeter . getGreeting ( ) ,  expectedGreeting) 

} 
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(cont’d) 


Greeter 


public  class  Greeter 
{ 

const  String  greeting  =  "Hello  World" 

Greeter ( ) 

String  getGreeting ( ) 

{ 

return  greeting 

} 


Very  Simple  TDD  Example 


Greeter  Test 


[Test] 

public  class  Greeter_Test 
{ 

const  String  expectedGreeting  =  "Hello  World" 
[TestMethod] 

public  void  TestDisplayHelloWorld ( ) 

{ 

Greeter  myGreeter  =  new  Greeter () 

Assert (myGreeter . getGreeting ( ) ,  expectedGreeting) 

} 


Compilation  Error 
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(cont’d) 


Greeter 


public  class  Greeter 

{ 

const  String  greeting  =  "Hello  World" 

private  Greeter () 

static  Greeter  Getlnstance () 

{ 

return  new  Greeter () 

} 

String  getGreeting ( ) 

{ 

return  greeting 

} 


Very  Simple  TDD  Example 


Greeter  Test 


[Test] 

public  class  Greeter_Test 
{ 

const  String  expectedGreeting  =  "Hello  World" 
[TestMethod] 

public  void  TestDisplayHelloWorld ( ) 

{ 

Greeter  myGreeter  =  Greeter .Getlnstance () 

Assert (myGreeter . getGreeting ( ) ,  expectedGreeting) 

} 
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(cont’d) 


Greeter 


public  class  Greeter 

{ 

const  String  greeting  =  "Hello  World" 

private  Greeter () 

static  Greeter  Getlnstance ( ) 

{ 

return  new  Greeter () 

} 

String  getGreeting ( ) 

{ 

return  greeting 

} 


Very  Simple  TDD  Example 


Greeter  Test 


[Test] 

public  class  Greeter_Test 

{ 

const  String  expectedGreeting  =  "Hello  World" 


[TestMethod] 

public  void  TestDisplayHelloWorld ( ) 


} 


} 


Assert (Greeter . Getlns tance ( ) . getGreeeting , 

expectedGreeting) 


Back 
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(cont’d) 


Greeter 


public  class  Greeter 

{ 

const  String  greeting  =  "Hello  World" 

private  Greeter () 

static  Greeter  Getlnstance ( ) 

{ 

return  new  Greeter () 

} 

String  getGreeting ( ) 

{ 

return  greeting 


} 


} 


